The present invention relates to information systems, and more specifically, to an approach for providing access to resources in information systems.
In information systems, processes require access to resources to perform work. As used herein, the term xe2x80x9cresourcexe2x80x9d refers to any object that can be accessed in an information system. In a hardware context, examples of resources include, but are not limited to, printers, disk drives and memory. In a software context, examples of resources include, but are not limited to, data items and routines. In information systems it is often desirable to allow only one process at a time to access a particular resource to maintain consistency. For example, if while a first process is updating a particular resource, a second process is allowed to read from the particular resource, then the second process may read an intermediate value of the particular resource that is different than the final value of the particular resource after the first process has completed its updates. As a result, the second process may erroneously believe that at the time the second process read from the particular resource, that the particular resource reflected all of the changes made by the first process. In this situation, an inconsistency has been introduced into the information system with respect to the value of the particular resource, thereby compromising the integrity of the data on the information system.
To address situations such as this, various mechanisms are used to ensure the integrity of resources that can be accessed by multiple processes. In particular, some information systems use locking mechanisms to manage and coordinate access to shared resources. In such systems, each process may be required to obtain a lock on a resource before accessing the resource. The type and parameters of the lock determine the scope of the access rights granted to the obtaining process. The appropriate grant of locks to resources ensures compatible access to the resources by concurrent processes. In the previous example, the first process would request and be granted a lock on the particular resource prior to updating the particular resource. While the first process holds the lock on the particular resource, the first process may make updates to the particular resource, but the second process may not access the particular resource. Once the first process has completed updating the particular resource, the lock is released. The second process can then access the particular resource and see all of the updates made to the particular resource by the first process.
Locks are typically allocated and managed by a process referred to as a lock manager. Lock managers are responsible for maintaining data that specifies the status of locks for a set of resources. Lock managers sometimes maintain a lock request queue for a set of resources to manage multiple lock requests. In distributed computing systems, resources, their assigned lock managers and processes obtaining locks on the resources may be located on separate nodes, or may be located on the same node. As used herein, the term xe2x80x9cnodexe2x80x9d refers to any type of computing entity. Thus, a single computer may be a single node or support multiple nodes.
One of the problems with locking mechanisms is that there are situations in which it is desirable to simultaneously grant locks to multiple processes for a particular resource. It is helpful to consider this problem in the context of transaction processing in database systems. In the context of database systems, a xe2x80x9ctransactionxe2x80x9d is a logical unit of work that is comprised of one or more database language statements.
Consider a situation where a first process P1 processing a transaction T1 obtains an exclusive lock LI on a resource R from a lock manager LM. A second process P2, that is also working on transaction T1, wishes to obtain a lock on resource R and submits a lock request to lock manager LM. Since lock L1 on resource R is currently granted to process P1, lock manager LM places the lock request from the second process P2 onto a lock request queue maintained by lock manager LM. When first process P1 releases its lock L1 on resource R, lock manager LM grants a lock L2 on resource R to another process in the order in which lock requests were received. If the lock request by process P2 is the first lock request for resource R in the lock request queue, then lock manager grants a lock to process P2. If however, a lock request for resource R by a third process P3 was received prior to the request by the second process P2, then a lock on resource R will be granted to third process P3 before the second process P2, irrespective of whether the third process P3 is working on transaction T1. Thus, second process P2 may or may not be the next process to be granted a lock on resource R, even though process P2 is processing transaction T1. This characteristic of lock mechanisms is undesirable for several reasons.
Sometimes it is desirable to directly migrate a lock on resource R from the first process P1 to the second process P2 so that the second process P2 can immediately continue processing of transaction T1 without losing the changes made by process P1. If, as in the prior example, process P3 is granted a lock on resource R before process P2, and process P3 begins processing a transaction other than T1, then the changes made to resource R by process P1 may be lost. Direct migration is often desirable for load balancing or efficiency purposes. For example, the first process P1 may be experiencing an extremely high processing load that can be reduced by migrating the processing of transaction T1 from the first process P1 to the second process P2. Alternatively, the second process P2 may be able to process transaction T1 more efficiently than the first process P1.
Another situation where direct migration is desirable is when the first process P1 fails, or the node on which first process P1 resides fails, and it is possible for another process to complete processing of transaction T1. In this situation, sometimes referred to as xe2x80x9cfailover,xe2x80x9d it is important to continue processing of transaction T1 before a process working on another transaction makes a change to resource R. Otherwise, changes made to resource R up to the point of failure of the first process P1 may be lost. With conventional locking mechanisms however, there is no way to guarantee that the process that is to continue processing of transaction T1 will be the next process that is granted a lock on resource R when the first process P1 releases its lock on resource R.
Suppose that the first process P1 has failed before completing transaction T1 and that the second process P2 is to continue processing of transaction T1. At the time of failure of the first process P1, a lock request for a lock on resource R is sent by the second process P2 to lock manager LM and placed on the lock request queue. When the lock held by the first process P1 is released, the lock manager LM grants a lock on resource R to the process associated with the first lock request in the lock request queue. If the lock request associated with second process P2 is first in the lock request queue, then the first transaction T1 can be completed by the second process P2. If, however, a lock request associated with a third process P3 is ahead of the lock request associated with the second process P2 in the lock request queue, then the lock is granted to the third process P3 before the second process P2. If the third process P3 is working on a transaction other than transaction T1, then the third process P3 may make updates to resource R, causing the changes made to resource R by the first process P1 up to the point that the first process P1 failed, to be lost. In this event, the changes made during the processing of the first transaction T1 will have to be undone and the first transaction T1 started again.
Sometimes, the nature of the failure of either the first process P1, or the node on which the first process P1 resides, can make continued processing of transaction T1 by another process either impractical or impossible. In these situations, a recovery process must rollback the changes made by transaction T1 before other processes can access resource R. If another process accesses resource R before the recovery process rolls back the changes made by transaction T1, then the other process risks working with an invalid state of resource R. With conventional locking mechanisms, there is no way to ensure that a lock on resource R can be granted to the recovery process before being granted to another process.
Therefore, based on the need to control access to resources by processes and the limitations in the prior approaches, an approach for controlling access to resources that does not suffer from limitations inherent in conventional locking approaches is highly desirable.
According to one aspect of the invention a method is provided for managing access to a particular resource. According to the method, a request is received for a first lock on the particular resource from a first process to allow the first process to make updates to the particular resource, wherein the first process is associated with a first transaction. A first lock on the particular resource is granted to the first process. A request for a second lock on the particular resource is received from a second process to allow the second process to make updates to the particular resource. A determination is made whether the second process is associated with the first transaction. If the second process is associated with the first transaction, then a second lock is granted on the particular resource to the second process prior to the first lock being released.
According to another aspect of the invention, a system is provided that comprises a resource and a locking mechanism for managing access to the resource. The locking mechanism is configured to grant a first lock on the resource in response to a request for a first lock on the resource from a first process to allow the first process to make updates to the resource, wherein the first process is associated with a first transaction. The locking mechanism is further configured to determine, in response to a request for a second lock on the resource from a second process to allow the second process to make updates to the resource, whether the second process is associated with the first transaction. If the second process is associated with the first transaction, then a second lock on the resource is granted to the second process prior to the first lock being released.
According to another aspect of the invention, a method is provided for managing access to a resource. According to the method, a first request for a first lock on a resource is received from a first process associated with a first transaction to allow the first process to make updates to the resource. A first lock on the resource is granted to the first process. After granting the first lock on the resource to the first process, a second request for a second lock on the resource is received from a second process associated with a second transaction to allow the second process to make updates to the resource. After receiving the second request, a third request for a third lock on the resource is received from a third process associated with the first transaction to allow the third process to make updates to the resource. Finally, the third lock on the resource is granted to the third transaction prior to granting the second lock on the resource to the second transaction in response to the third process being associated with the same transaction as the first process.